The Internet has experienced explosive growth over the past decade. While a significant portion of the sites on the Internet are only visited rather infrequently, a number of sites and their associated services are called upon to support hundreds of thousands of simultaneous connections. In some instances, the processing load is such that the workload generated by active requests must be distributed to a large number of servers to avoid excessive delays. Information sites/portals are examples of such sites.
However, other sites/web-based services, due to the nature of their services, can support the hundreds of thousands of simultaneous connections using a single server node. Examples of such services are web-based email and instant messaging. Because users are typically connected to the server in a mode where no action needs to be taken by the server, the server is able to handle most user loads without substantial degradation of service even when a very large number of open connections are being serviced. In such instances, however, maintaining the connections, and in particular their associated Transmission Control Protocol (TCP) timers, can impose a significant load on the server's processor(s).
The well-known (and documented) Transmission Control Protocol supports a number of scheduled event timers for each connection. These timers include, among others: (1) retransmission, (2) Delay-Acknowledgement, (3) Push, (4) Silly-Window-Syndrome prevention, (5) Finish-Wait-2-State, and (6) Connection establishment/disconnection. In a system incorporating TCP to maintain and support connections over, for example, the Internet, the TCP timers are maintained in a transmission control block (TCB).
During the lifetime of a TCP connection, a number of events are scheduled on the connection to occur after a specified period of time. For example, the protocol may not indicate “data received” from the network immediately to a user. Instead it waits for a period of time (e.g., 500 msec.) to ensure that there is no more data to be received from the network. The protocol schedules an “indicate data” action on the connection to fire after the 500 msec. wait period expires.
In another example, if data is sent on a connection, a timer corresponding to a “retransmit” action is set and the protocol waits for a period of time for acknowledgement from the intended recipient. If such an acknowledgement is not received within the wait period, then the timer fires, and the data is retransmitted. The timer is cleared if the acknowledgement is received prior to expiration of the wait period.
To schedule such actions, the protocol sets an appropriate timer within the TCB. A timer management framework accesses the timers, notes when one has expired, and invokes a proper handler routine.
In a known TCP timer handling scheme, the protocol includes a timer handler procedure that is invoked once every timer tick (100 msec.). The timer handler walks through the set of all TCBs every 100 msec. searching for scheduled actions that have now become current. While such a task imposes a trivial load on a server supporting a thousand or so concurrent connections, servicing the timers can consume significant CPU resources when hundreds of thousands of connections are simultaneously supported.